I updated my *64-current yesterday and the upgrade included the new pulseaudio_13.0 package. This broke the nvidia driver/kernel sound even after rebuilding/reinstalling these packages with the new kernel v4.19.73. The MO was the Audio Setup GUI (Phonon multimedia framework) no longer displayed my nvidia hardware but displayed only the Pulseaudio Server instead. I was able to get sound out but only via the "Test" play button and only in my User account (not root!). The KDE Workspace Notifications setting no longer played sounds (login etc) or any other player/device for that matter - again sound only functioned in the KDE Audio GUI test mode. My first thought was this was an issue with the new kernel. This was not the case. I solved the issue by downgrading the Pulseaudio package to the previous version (12.2) which worked just fine in the 4.19.69 kernel.

In any event folks having similar issues might want to downgrade their pulseaudio.

Sould I bring this to the attention of the Slackware Team, Pulseaudio or both?

By creating this thread you already brought your issue to the attention of the Slackware Team. Some more details should have been provided to be able to understand what was happening on your system. I'm sure the pulseaudio devs will also require these, should you raise this problem of yours with them.

If you plan to give pulseaudio 13 another try, please check/provide the following:
- in alsamixer - check if any outputs are on (auto)mute
- provide the outputs of:
You could run the last two pacmd commands as both the user and root - see if there's a difference or if pulseaudio is even launching for root.
To start & stop pulseaudio, run:

Hi 'abga',

Just a follow-up to our previous thread...

Yesterday I updated my Slackware64-current with the slackpkg tool (great tool!). I forgot to blacklist pulseaudio however and the 13.0 package got reinstalled. This of course produced the same result as before - clobbering my working KDE sound system. So I decided since I had this setup again I would give you the details you requested. I will preface this with the caveat that the Pulse Audio Sound server is not meant to be used with KDE. KDE has its own sound server 'Akonadi'. Since Slackware uses KDE as the default desktop the pulseaudio sound daemon/server is not started at boot [i.e. /etc/rc.d/rc.pulseaudio is not set to executable permission]. So I did a little more digging into this.

First here is the output you requested:
root@kiai1:~# cat /proc/asound/cards
0 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xf7080000 irq 54
1 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xf7700000 irq 56
root@kiai1:~# cat /proc/asound/pcm
00-03: HDMI 0 : HDMI 0 : playback 1
00-07: HDMI 1 : HDMI 1 : playback 1
01-00: ALC1220 Analog : ALC1220 Analog : playback 1 : capture 1
01-01: ALC1220 Digital : ALC1220 Digital : playback 1
01-02: ALC1220 Alt Analog : ALC1220 Alt Analog : capture 1
root@kiai1:~# pacmd list-cards
No PulseAudio daemon running, or not running as session daemon.
root@kiai1:/usr/bin# pacmd list-sinks
No PulseAudio daemon running, or not running as session daemon.

So just for fun I made the above run-level start-up script executable and started the pulseaudio sound server (along side KDE's akonadi).
root@kiai1:~# /etc/rc.d/rc.pulseaudio start
root@kiai1:~# ps -ef | grep pulseaudio
pulse 1469 1 0 17:59 ? 00:00:00 /usr/bin/pulseaudio --system --disallow-module-loading


Listing the cards and sinks as above gives the same result. This is likely because we are not executing '/usr/bin/start-pulseaudio-x11' either with KDE.

Recall I told you I could only get sound through the "Test" button in the Akonadi Sound Setup GUI. Well when I started pulseaudio server/daemon it totally disabled sound output even through the "Test" button. Killing the pulseaudio daemon restored sound but again only with the Akonadi "Test button".


IMHO this is a bug with the latest release of pulseaudio v13.0 (not KDE) since this behavior was not exhibited in previous releases of pulseaudio. You should be able to have the package installed without running the server/daemon - but that is only my humble opinion.

I would love to get sound working with Pulse if it meant I didn't have to recompile the Nvidia kernel/driver each time I updated my kernel. This is a royal P.I.T.A.!!!

Hope all this is helpful.
--wirelessmc

Wow! Just another data point that was completely unexpected...

KDE relies on the pulseaudio package apparently. When I completely removed the pulseaudio-13.0 package (even though I still had the pulseaudio-compat32-13.0-x86_64-1compat32 package installed!) KDE would NOT start! I had to reinstall the older package "pulseaudio-12.2-x86_64-2" in order for KDE to start. Needless to say this was surprising.

1 members found this post helpful.

I think you have a few misconceptions. KDE most certainly does use pulseaudio by default on 14.2 and newer. Akonadi is a database system developed by KDE for KDE, but can be used by any desktop to "store, index and retrieve the user's personal information". It does not act as a subsystem for sound. See their website for more details on it.

What you're probably thinking of is phonon, which is KDE's multimedia API. This is in the same realm as gstreamer. But these require additional sound system components (alsa, pulseaudio, jack, etc). By default, KDE will route all sound through pulseaudio. This is because KDE is compiled with pulseaudio support. But Pat has added the easy ability to -current to remove pulseaudio by replacing all the system packages requiring pulseaudio with packages compiled for only alsa support. This is located in the in the extra/pure-alsa-system/ folder on your installation media or favorite server.

The reason rc.pulseaudio is not set to run is because it isn't recommended to run it systemwide (see the quote below out of the rc.pulseaudio file). Normally, your WM/DE will start pulseaudio on a per-user basis, KDE included.

If you can confirm this is related to pulseaudio (keep the rest of your system the same and try and rebuild the upgraded pulseaudio and the problem still occurs), then it would be best to bring up the issue to the pulseaudio devs.

3 members found this post helpful.

If you remove pulseaudio, it will break several system packages, including KDE, XFCE, mplayer, ffmpeg, and more. That is why Pat has decided to include the ability to run a pure-alsa system in the extra/ folder on your favorite mirror. This will replace all the packages that require pulseaudio with ones that were compiled without support for it.

https://mirror.slackbuilds.org/slack...e-alsa-system/

2 members found this post helpful.

Interesting, wondering which of the available outputs you actually want to use - HDMI(digital) on Nvidia/Intel or the analogue out on the HDA-Intel sound chip? You haven't specified that and my initial presumption was that in pulseaudio 13 you had a different output (reorder) as the default, that's the one you expected and was working in pulseaudio 12.2. For this purpose I asked you to provide the outputs of those pacmd commands.
Now, it really bothers me that the pacmd utility doesn't recognize pulseaudio running, even if you checked that manually and the result was positive. I fear that either you ran the pacmd commands too late after launching pulseaudio, which automatically exits on idle and has in /etc/pulse/daemon.conf a directive called "exit-idle-time =" from where you could tune the wait time, or you have some issues wit pulseaudio itself - it's not loading properly / at all.
First case, just run these commands at once, copy-paste them to make sure you don't wait too much between the pulseaudio launch and the pacmd commands:
If you still get the "No PulseAudio daemon running, or not running as session daemon." error message, then move to investigating if&how pulseaudio launches, run it manually in verbose mode and inspect the output (you can redirect it to a file):
On the use of pulseaudio by KDE & other apps, bassmadrigal already provided you with all the info you need. You don't need pulseaudio running system wide (set rc.pulseaudio on executable) as pulseaudio is auto-launching a user instance by default if an app requests it, for details have a look at:
https://www.freedesktop.org/wiki/Sof.../User/Running/

1 members found this post helpful.

Many thanks to all (bassmadrigal and abga) for your guidance/inputs. I was working with 'wabbits' on the #pulseaudio channel over on freenode (IRC) and we did a number of diagnostic things from the (bash) shell as well as with PulseAudio volume control GUI (/usr/bin/pavucontrol). On my system there are two audio devices:

0) GP108 High Definition Audio Controller Digital Sterio (HDMI)
1) Family 17h (Models 00h-ofh) HD Audio Controller Digital Sterio (IEC958)

For some reason with the pulseaudio_13.0 package installed it was not pointing to the default output device in ALSA (0 above). This was not the case with pulseaudio_12.2 package. I need it to be 0 in my case since the only audio output device I have is through my built-in speaker in my display.

Other folks with a similar setup as mine may need to do the following to set the correct (default) fallback device.

1) Bring up the pavucontrol gui above and navigate to the "Output Devices" tab.
2) To the right of each device output port are two little icons (a lock & a green check mark). Be sure to select the correct device fallback button (green check mark button). When you do you will note it becomes highlighted. On my system it wasn't very noticeable as the background is grey.

That should resolve your pulseaudio_13.0 audio issue if it you have one and didn't in pulseaudio_12.2.

1 members found this post helpful.

@wirelessmc

If you don't want to manually set the output with pavucontrol on every start, you could follow the discussion and solution from this thread and make your preferred output default:
https://www.linuxquestions.org/quest...ue-4175633510/

It seems what I (and #wabbits) did with the pacvucontrol is persistent. There is no need to reset it after this procedure. I should have mentioned that in my previous post. My apology for the omission.

Care to share the "what I (and #wabbits) did with the pacvucontrol is persistent" with the community here? Thanks!

abga wrote yesterday 10/10 at 10:19 a.m. PDT:

Care to share the "what I (and #wabbits) did with the pacvucontrol is persistent" with the community here? Thanks!

Sure thing abga. Just to reiterate. It took a number of diagnostic steps to get here but once #wabbits examined the logs from running the script (on my box) at https://www.freedesktop.org/wiki/Sof...oubleshooting/ (see below*) - we brought up the /usr/bin/pavucontrol GUI and did the following (below is clip from my post on 10-9-19 10:58 p.m. PDT (GMT-7)):


1) Bring up the pavucontrol gui above and navigate to the "Output Devices" tab.
2) To the right of each device output port are two little icons (a lock & a green check mark). Be sure to select the correct device fallback button (green check mark button). When you do you will note it becomes highlighted. On my system it wasn't very noticeable as the background is grey.


One other thing #wabbits noted from the logs was that the module "module-device-manager" was running under the 12.2 package. This is no longer loaded by default in the 13.0 package. So you might also try forcing the load in the /etc/pulse/default.pa by adding the following line:

load-module module-device-manager


*trouble shooting script $> curl https://gitlab.freedesktop.org/pulse...o?inline=false | bash | nc termbin.com 9999
(above should be run as user from bash shell not root account)

2 members found this post helpful.